Companion Guide for Test Automation

VRTPKS Test Plan

Version 1.4 | Sept 2025

Important Note on Confidentiality, Disclaimers and Copyright

© 2025 Visa. All Rights Reserved.

Confidentiality: This document, and the information set out in this document, is proprietary and CONFIDENTIAL to Visa. It is distributed to you by Visa as a participant in the Visa payments system for your use only to the extent necessary to enable Visa programs. You acknowledge that the information contained herein (the 'Information') is confidential and subject to confidentiality restrictions contained in Visa's operating regulations or other confidentiality agreements that limit your use of the Information. In no event may this document or its information be duplicated, published, distributed, or disclosed, in whole or in part, to any third party, individual, or any other person, without prior written permission from Visa, and without expressly limiting by way of contract that person's use of this document and the information it contains to assisting you in managing your Visa programs. This document and the information set out in this document may not be used in connection with, or to support, any non-Visa programs or any non-Visa payment network, system, or scheme, including any non-Visa program that is co-badged or co-resident with a Visa program, in each case, without Visa's prior written consent.

Trademarks: The trademarks, logos, trade names and service marks, whether registered or unregistered (collectively the "Trademarks") are Trademarks owned by Visa. All other trademarks not attributed to Visa are the property of their respective owners.

THIS PUBLICATION IS PROVIDED ON AN "AS IS", "WHERE IS", BASIS, "WITH ALL FAULTS" KNOWN AND UNKNOWN. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, VISA EXPLICITLY DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, REGARDING THE LICENSED WORK AND TITLES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT.

THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL AND MUST BE MAINTAINED IN CONFIDENCE IN ACCORDANCE WITH THE TERMS AND CONDITIONS OF THE SPECIFICATION LICENSE OR OTHER WRITTEN AGREEMENT BETWEEN YOU AND VISA INC., VISA INTERNATIONAL SERVICE ASSOCIATION, AND/OR VISA EUROPE LIMITED.

Table of Contents

• Document Version History
• Introduction
• General Information
  • Audience
  • Reference Materials
  • Definitions and Acronyms
• Companion Guide: Checklist
  • I. General Requirements
  • II. Automation Requirements
    • Reader Controller Software
    • Kernel Software
    • Host Simulator
  • III. Scenarios Testing
  • A. Single Run
    • Steps to Perform the Single Run Test
  • B. Batch Runs
    • Steps to Perform the Batch Run Test
    • Batch Run - Test 1 to 20
• 1 Overview
  • 1.1 Automation Setup (Automated Testing)
• 2 Automation Requirements
  • 2.1 Reader Controller
  • 2.2 Test Message
    • 2.2.1 Transaction Configuration (STXN)
  • 2.2.2 Transaction Outcome (ETXN)
  • 2.3 Kernel Integration
  • 2.4 Transaction Configuration
    • 2.4.1 General
    • 2.4.2 Pre-processing and DRL
    • 2.4.3 Expected Host Response
    • 2.4.4 Certification Revocation List
    • 2.4.5 Online ODA
• 3 Online-Only
• 4 AID
• 5 Date Time Requirement
• Appendix A Test Message
  • A.1 Overview
  • A.2 HTTP Message
  • A.3 Start of Transaction (STXN)
  • A.4 End of Transaction (EXTN)
  • A.5 ECHO
  • A.6 Scenarios and Error Handling
    • A.6.1 General - No Host Response
    • A.6.2 General - Bad Request Format
    • A.6.3 General - Server Busy, Request Timeout
    • A.6.4 General - Error Message
    • A.6.5 Connection and Messaging Protocol Test
    • A.6.6 Test Execution
    • A.6.7. Test Execution - Stop on Error
    • A.6.8 Multiple Start of Transaction (STXN) Messages
    • A.6.9 Multiple End of Transaction (ETXN) Messages
    • A.6.10 End of Transaction (ETXN) Message with Wrong Test_ID
    • A.6.11 Echo in Between Messages
    • A.6.12 Unexpected Flow of Message
• Appendix B Reader Status and Event
  • B.1 Outcome Events
  • B.2 Other Events
  • B.3 Additional Checks
• Appendix C Reader Controller Verifier Tool
• Appendix D Frequently Asked Questions (FAQ)
  • D.1 General
  • D.2 Architecture and Protocol Handling
  • D.3 Product Features and Configurations

Document Version History

Document Version History

Date	Version Number	Description
March 2021	1.0	First publication
October 2021	1.1	Modifications for VRTPKS v1.2 (Transit feature): Section 2.4 Updated sample XML to latest structure Table 2-1 Added Version, POI Information (tag 8B) and Merchant Category Code (tag 9F15) Table 2-1 Remove remarks for elements that are now applicable for Transit feature implementation Section 2.4.1 Updated sample XML to latest structure Table 2-2 Updated elements applicable to Transit feature Section 2.4.4 Added section for CRL configuration Section 2.4.5 Added section for Online ODA configuration Appendix A.4 Table A-2 Added setting of Transaction_Outcome bits 4-1 for Transit implementations. Appendix B Added new events information for transit Clarifications Section 2.4 Clarify to also ignore unknown element Section 2.4.3 Clarify definition of tag 8A values Section 4 Clarify that full and partial AID matching is enabled and supported by default
March 2024	1.2	Table 2-1 Updated Version to Version 1.2 Added optional attribute “Info” to <Configuration> Updated sample <Configuration> figure before Table 2-1 Table A-2 Removed IRWIN data content Table A-3 Updated the description before the table Updated to include DE_5F20 Appendix B.1 Added EVT_NOTIFY_OUTCOME_DECLINED_OR_TERMINATE
Feb 2025	1.3	Document format changes to .html Some format changes within document with no technical content changes made
September 2025	1.4	Companion Guide Checklist Added 2 new test cases Transaction Configuration, Date Time Requirement, AID Allow Reader Controller to configure Transaction Date (Tag 9A) and Application Identifier (Tag 9F06) during test execution New chapter for Date Time Requirement information. Outcome If output of ASRPD and VISA Fleet Data Objects is supported, include this as a conditional output for expected acquirer data. Various editorial updates

Introduction

This document serves as a companion guide for Tap to Phone kernel implementations to support the testing automation designed for Visa Ready Tap to Phone Kernel Specification (VRTPKS) Level 2 Type Approval.

The automation requirements described in this document are designed solely for testing purposes only.

General Information

Audience

This document is intended for Product Vendors that are seeking Visa recognition of their Tap to Phone kernel (VRTPKS) implementations.

Reference Materials

Reference	Document
VCPS	Visa Contactless Payment Specification (VCPS): Reader Specification, Version 2.2, and all published updates
VRTPKS	Visa Ready Tap to Phone Kernel Specification Version 1.2 and all published updates
VRTPKS Test Plan	VRTPKS Test Plan
Test Tool Technical Requirements	Visa Test Tool Technical Requirements for Reader Test Plans Version 1.0 and all published updates
EMV SB 230	EMV Specification Bulletin No. 230 Technical Information to Enhance Contactless Application Selection
EMV Book 2	EMV Book 2 – Security and Key Management Version 4.4 and all future updates

Definitions and Acronyms

Acronym	Definition
Type Approval	Verification by Visa that a specific product has demonstrated sufficient conformance to the Visa specifications
Device Applications	A Kernel or Embedded Software loaded into a Physical Reader/Terminal
Product Provider	The entity that submits a Visa product to Visa for Type Approval
Test Case	A description of the actions required to achieve a specific test objective
Test Tool Vendor	An entity that submits a test tool to Visa for recognition
IRWIN	Intelligent qVSDC Readers With Implementation Notes
AOSA	Available Offline Spending Amount
RC Verifier	Reader Controller Verifier Software
DE	Data Element
ODA	Offline Data Authentication

Companion Guide: Checklist

This form serves as a checklist for the usage of VRTPKS Test Plan and compliance with its automation requirements. Go through the checklist to ensure compliance with all the requirements for test automation.

I. General Requirements

Answer YES or NO to each question.

YES/NO	Question
YES	Does the product support Online-only feature? (Acceptable Answer: YES. Refer to Chapter 3 Online-Only Readers)

II. Automation Requirements

Answer YES or NO to each question for all three sections.

Reader Controller Software

Does the Reader Controller Software:

YES / NO	Question
YES / NO	Implement Test Messages STXN, ETXN and ECHO? (Refer to Section 2.2 Test Message and Appendix A Test Message)
YES / NO	Implement the applicable scenarios and error handling described for Test Message protocol? (Refer to Appendix A.6 Scenarios and Error Handling)
YES / NO	Implement ALL the Configuration tags in STXN message when supported? (Refer to Section 2.2.1 Transaction Configuration (STXN) and Section 2.4 Transaction Configuration)
YES / NO	Implement ALL the Transaction Details tags in ETXN message when supported? (Refer to Section 2.2.2 Transaction Outcome (ETXN) and A.4 End of Transaction (EXTN))
YES / NO	Provide an interface to configure number of retries and delay in milliseconds in between Test Messages? (Refer to Appendix A.6.3 General - Server Busy, Request Timeout)
YES / NO	Provide an interface to test the communication channel to/from the server (using ECHO)? (Refer to Appendix A.5 ECHO)
YES / NO	Provide an interface to configure the IP Address and Port of the host that it can connect to? (Refer to Appendix A Test Message)

Kernel Software

Does the Kernel Software interface interact with the Reader Controller Software to:

YES / NO	Question
YES / NO	Receive the equivalent STXN Transaction Configuration?
YES / NO	Auto start the transaction?
YES / NO	Provide the Transaction Details after a transaction is performed? (Refer to Section 2.3 Kernel Integration)

Host Simulator

Does the Host Simulator interact with the Reader Controller Software to:

YES / NO	Question
YES / NO	Receive and configure the Expected Host Response from STXN message? (Refer to Section 2.4.3 Expected Host Response)

III. Scenarios Testing

The scenario checks described in this section is designed for the Reader Controller software to run with the Visa-complimentary Reader Controller Verifier Software (see Appendix C Reader Controller Verifier Tool for usage) and a Test Card (provided upon request).

All tests verdicts shall be a PASS or NA (NA only if feature is not supported) to ensure compliance with automation requirements.

A. Single Run

Single run test cases are designed to be executed one-by-one following the messaging protocol for single run (Appendix A.6.6a). The test cases are designed to try out variations of transaction configuration and transaction outcomes.

Steps to Perform the Single Run Test

For each test case:

1. Assess the Applicability (column 3), if all the features are supported then the test can be performed else mark in the verdict (column 5) as NA. All NOT SUPPORTED features for VRTPKS are by default answered NA.
2. If the test can be performed, select the scenario and test case from the RC Verifier and press RUN.
3. Mark the test verdict (column 5):
   • If the test passed with RC Verifier and Visual Check requirements (column 4) are met, mark as PASS. Otherwise, mark as FAIL.

Test ID	Test Case Description	Applicability	Visual Check Requirements	Verdict: PASS / FAIL / NA
Test_01	$2.00 purchase transaction	Applicable for all	None	User to update verdict
Test_02	$2.00 purchase transaction (Online)	Applicable for all	None	User to update verdict
Test_03	-	NA	NA	NA
Test_04	-	NA	NA	NA
Test_05	-	NA	NA	NA
Test_06	-	NA	NA	NA
Test_07	-	NA	NA	NA
Test_08	-	NA	NA	NA
Test_09	Acquirer Messaging	Applicable for all	None	User to update verdict
Test_10	-	NA	NA	NA
Test_11	Signature and CD CVM supported by both card and reader	- CVM Required Limit Check Supported - Signature Supported	Verify signature is not acquired	User to update verdict
Test_12	Online PIN supported by both card and reader	- CVM Required Limit Check Supported - Online PIN Supported	Verify Online PIN is performed	User to update verdict
Test_13	-	NA	NA	NA
Test_14	-	NA	NA	NA
Test_15	-	NA	NA	NA
Test_16	AID Printing	Printing of a Receipt for Approved Transaction Supported	Verify AID value is printed	User to update verdict
Test_17	Amount Display	Display Amount, Authorized when prompting for Card Presentation Supported	Verify accurate amount, authorized (tag 9F02) is displayed is not acquired	User to update verdict
Test_18	Request Present Card Remove Card in Progress	Applicable for all	- Verify card is request to be presented - Verify that the reader indicated to the cardholder and merchant that card read is complete and that the card may be removed, but that the transaction is still in progress.	User to update verdict
Test_19	Update Terminal Date Setting (Tag 9A)	Applicable for all	None	User to update verdict
Test_20	Update Terminal AID (Tag 9F06)	Applicable for all	None	User to update verdict

B. Batch Runs

Batch run scenarios are designed to execute test cases in batches following the messaging protocol for Batch run (Appendix A.6.6b) and Server Busy tests (Appendix A.6.3). These test cases are designed to run in full automation and does not require visual checks.

Steps to Perform the Batch Run Test

For each scenario:

1. Select the scenario from the RC Verifier and press RUN.
2. Mark the test verdict column:
   • If the test passed with RC Verifier, mark as PASS. Otherwise, mark as FAIL.

Batch Run - Test Batch 1 to 5

Scenario/Test ID	Verdict: PASS / FAIL
Test_Batch_01	User to update verdict
Test_Batch_02	User to update verdict
Test_Batch_03	User to update verdict
Test_Batch_04	User to update verdict
Test_Batch_05	User to update verdict

Batch Run - Server Busy at Beginning

Scenario/Test ID	Verdict: PASS / FAIL
Test_Batch_01	User to update verdict
Test_Batch_02	User to update verdict
Test_Batch_03	User to update verdict
Test_Batch_04	User to update verdict
Test_Batch_05	User to update verdict

Batch Run - Server Busy at Middle

Scenario/Test ID	Verdict: PASS / FAIL
Test_Batch_01	User to update verdict
Test_Batch_02	User to update verdict
Test_Batch_03	User to update verdict
Test_Batch_04	User to update verdict
Test_Batch_05	User to update verdict

Batch Run - Test 1 to 20

Batch run (Test 1 to Test 20) scenario is designed to test the robustness of the implementation of messaging protocol. These test cases are derived from Single Run. Reader Controller will run ALL of the following test cases in Batch Run Mode. The same applicability shall be employed and mark the test case as NA if not applicable. Visual checking is not required while running this test.

Steps to perform the test:

1. Assess the applicability; the same applicability shall be applied based from Single Run test cases.
   • Mark the non-applicable test case as NA. NOT SUPPORTED features for VRTPKS are by default answered NA.
2. Select Batch Run - Test 1 to 20 scenario from the RC Verifier and press RUN.
3. Mark the test verdict column:
   • If the test is NA, ignore the verdict from RC Verifier.
   • If the test is applicable, check the verdict from RC Verifier and mark as PASS or FAIL.

Batch Run - Test 1 to 20

Scenario/Test ID	Verdict: PASS / FAIL
Test_01	User to update verdict
Test_02	User to update verdict
Test_03	NA
Test_04	NA
Test_05	NA
Test_06	NA
Test_07	NA
Test_08	NA
Test_09	User to update verdict
Test_10	NA
Test_11	User to update verdict
Test_12	User to update verdict
Test_13	NA
Test_14	NA
Test_15	NA
Test_16	User to update verdict
Test_17	User to update verdict
Test_18	User to update verdict
Test_19	User to update verdict
Test_20	User to update verdict

1 Overview

This document describes the automation requirements for VRTPKS Test Plan Level-2 Type Approvals.

This document provides information how the Test Plan materials shall be used and the technical requirements for Products in order to achieve automation.

For Test Tools, a separate document Test Tool Technical Requirements is available to describe the usage of VRTPKS Test Plan into their development.

1.1 Automation Setup (Automated Testing)

This figure describes the role of 3 entities in test automation:

• Test Tool
• Reader Controller (provided by the product vendor)
• Physical Reader (product-under-test)

On a high level, the Test Tool:

• Communicates with the Reader Controller to deliver transaction configurations and receive transaction outcomes.
• Provides card emulation of any form (e.g. via card probe or via physical card) that is to be used for each test case execution.
• Provides UI guidance to the test executor such as:
  • ICS declaration form entry
  • Displaying test steps and instructions to perform a test
  • Displaying user prompts to confirm status, events and visual checks
  • Displaying the test verdict
• Validate the APDUs and transaction outcomes
  
  

On a high level, the Reader Controller:

• Communicates with the Test Tool to receive the transaction configuration and pass it to the Physical Reader.
  • Note:Transaction Configuration in this figure represents the content of Start-of-Transaction message response as described in Appendix A
• Retrieves the Transaction Outcome from the Physical Reader and subsequently submit this information to the Test Tool.
  • Note:Transaction Outcome in this figure represents the content of End-of-Transaction message request as described in Appendix A
    
    

On a high level, the Physical Reader/Terminal (i.e. product-under-test):

• Communicates with the Reader Controller to receive transaction configuration
  • Note: Transaction Configuration in this figure represents the content of Start-of-Transaction message response as described in Appendix A
• Performs transaction based on the transaction configuration
• Submits transaction outcome to the Reader Controller
  • Note: Transaction Outcome in this figure represents the content of End-of-Transaction message request as described in Appendix A Test Message
    

Both the Test Tool and Reader Controller follows the Test Message protocol as defined in Appendix A Test Message

Messaging between the Reader Controller and the Physical Reader is vendor proprietary and is out of scope from this document.

2 Automation Requirements

The following are the requirements that the VRTPKS implementation shall follow to meet the automation requirements.

2.1 Reader Controller

The Product Provider shall submit a "Reader Controller" software that communicates with the Test Tool as described in Figure 1.

The "Reader Controller" software shall be developed as an external kernel or external application from Product-Under-Test.

The "Reader Controller" software may or may not reside inside the payment acceptance device.

All "Reader Controller" software and all its parts shall be removed after testing has completed.

Note: A VISA-complimentary software "Reader Controller Verifier" is a tool provided together with the VRTPKS Test Plan package to assist in the Reader Controller developments. This software mimics the "Server" part of the communication protocol as defined in Appendix A along with simulation of various scenarios defined in Section A.6 Scenarios and Error Handling. Details about this tool is discussed in Appendix C.

2.2 Test Message

The "Reader Controller" software shall implement the Test Message requirements as defined in Appendix A. Some additional notes below for implementation of Test Message:

2.2.1 Transaction Configuration (STXN)

During a Start of Transaction (STXN) message exchange, the Reader Controller software receives a string in XML Format. The XML will have a root tag <Configuration> that contains the transaction configuration that needs to be interpreted by the Reader Controller to meet the testing requirements. This includes dynamic configuration of the following:

1. Physical Reader-Terminal and;
2. Host Simulator (Proprietary to Product vendors)

See section 2.4 Transaction Configuration for the full details of the <Configuration> tag.

2.2.2 Transaction Outcome (ETXN)

At the end of each transaction, the Reader Controller software shall be able to extract the Transaction Outcome from the product-under-test. The transaction outcome is the resultant outcome of a transaction from the Reader-Terminal regardless of the card response. The outcome code and Acquirer Data along with the Test_ID shall be sent to the Test Tool via the End of Transaction (ETXN) message.

See Appendix A.4 End of Transaction (EXTN) for ETXN format and content details.

2.3 Kernel Integration

Along with automation, the Physical Reader/Terminal "Kernel" integration may need be modified to support communication with its own "Reader Controller" software as described in Figure 1 to:

1. Apply the Transaction Configuration received from the Reader Controller
2. Auto-start the Transaction based on the received Transaction Configuration
3. Communicate the Transaction Outcome to the Reader Controller

Note: The communication protocol between the "Reader Controller" and "Kernel" is Product Vendor proprietary and is out-of-scope from this document.

2.4 Transaction Configuration

The VRTPKS Test Plan uses the <Configuration> XML structure and elements to define a transaction configuration.

Each element shall be evaluated to determine whether the element is associate to a feature. If it is associated to a feature, determine whether the Product supports the feature.

If an element is associated to a feature OR if the associated feature of the element is supported by the reader, (for example, <DRL> element is tied to DRL feature and the feature is supported), then that element shall be made configurable by the Product Provider through Reader Controller.

Else, if the associated feature of an element is not supported or is unknown (e.g. <DRL> element is tied to DRL feature and this feature is not supported or an unknown element is present), then that element shall be ignored by the reader all throughout the test plan execution.

Sample <Configuration>

<Configuration Test_ID="T_Sample_01" Config_ID="config_1" Version=" 1.2">
    <General>
        <Tag name="Transaction Currency Code" ID="5F2A">0840</Tag>
        <Tag name="Transaction Currency Exponent" ID="5F36">02</Tag>
        <Tag name="Transaction Type" ID="9C">01</Tag>
        <Tag name="Amount, Authorized (Numeric)" ID="9F02">000000000200</Tag>
        <Tag name="Amount, Other (Numeric)" ID="9F03">000000000000</Tag>
        <Tag name="Terminal Country Code" ID="9F1A">0840</Tag>
        <Tag name="Terminal Floor Limit" ID="9F1B"/>
        <Tag name="Merchant Name and Location" ID="9F4E"/>
        <Tag name="Online-Only Reader Enabled" ID="ONLINE_ONLY_READER_ENABLED">True</Tag>
        <Tag name="AUC, Manual Cash Check Enabled" ID="AUC_MANUAL_CASH_CHECK_ENABLED">False</Tag>
        <Tag name="AUC, Cashback Check Enabled" ID="AUC_CASHBACK_CHECK_ENABLED">False</Tag>
        <Tag name="IRWIN, Do Not Transmit" ID="IRWIN_DO_NOT_TRANSMIT"/>
        <Tag name="POI Information" ID="8B"/>
        <Tag name="Merchant Category Code" ID="9F15"/>
        <Tag name="TTQ - MSD Support" ID="TTQ_MSD_SUPPORT">False</Tag>
        <Tag name="TTQ - qVSDC Support" ID="TTQ_QVSDC_SUPPORT">True</Tag>
        <Tag name="TTQ - Offline Only Reader" ID="TTQ_OFFLINE_ONLY_READER">False</Tag>
        <Tag name="TTQ - Online PIN Support" ID="TTQ_ONLINE_PIN_SUPPORT">False</Tag>
        <Tag name="TTQ - Signature Support" ID="TTQ_SIGNATURE_SUPPORT">False</Tag>
        <Tag name="TTQ - ODA For Online Authorization Support" ID="TTQ_ODA_FOR_ONLINE_AUTHORIZATION_SUPPORT">False</Tag>
        <Tag name="TTQ - Mobile Functionality CDCVM Support" ID="TTQ_MOBILE_FUNCTIONALITY_CDCVM_SUPPORT">True</Tag>
    </General>
    <Exception_File_Check Enabled="False"/>
    <Pre-processing Enabled="False"/>
    <DRL Enabled="False"/>
    <Expected_Host_Response/>
    <Certification_Revocation_List/>
    <Online_ODA/>
</Configuration>

Table 2-1: XML Elements and Attributes within <Configuration>

XML Element / Attribute	Description	Presence	Example Value
Configuration	Container element for Transaction Configuration Mandatory Contains below static elements (always present): <General> <Exception_File_Check> <Pre-processing> <DRL> <Expected_Host_Response> <Certification_Revocation_List>	Mandatory	--
Version	An attribute that contains the version of the contents of <Configuration>. This attribute is informational only and facilitates the version of the structure of transaction configurations. This document follows Version 1.3	Optional	1.3
Info	An attribute that contains information of the test. This attribute is informational only.	Optional	"VRTPKS Test Plan v1.2b,VRTPKS_Default"
Test_ID	The test case identifier	Mandatory	"T_5_85_C01_01"
Config_ID	The equivalent configuration file identifier config_<running number>.xml. Test cases using the same unique Config_ID uses the same configuration details. Note: Reader applications can use this identifier to control and minimize parameter updates to the reader-terminal and/or host simulators.	Mandatory	"config_1"
General	Container element that contains the general configuration expected from both the reader-terminal and the transaction. Always contain the following Tag IDs: 5F2A (Transaction Currency Code) 5F36 (Transaction Currency Exponent) 9C (Transaction Type) 9F02 (Amount, Authorized (Numeric)) 9F03 (Amount, Authorized Other (Numeric)) 9F1A (Terminal Country Code) 9F1B (Terminal Floor Limit) 9F4E (Merchant Name and Location) 9A (Transaction Date) 9F06 (Terminal Application Identifier) ONLINE_ONLY_READER_ENABLED AUC_MANUAL_CASH_CHECK_ENABLED AUC_CASHBACK_CHECK_ENABLED IRWIN_DO_NOT_TRANSMIT TTQ_MSD_SUPPORT TTQ_QVSDC_SUPPORT TTQ_OFFLINE_ONLY_READER TTQ_ONLINE_PIN_SUPPORT TTQ_SIGNATURE_SUPPORT TTQ_ODA_FOR_ONLINE_AUTHORIZATION_SUPPORT TTQ_MOBILE_FUNCTIONALITY_CDCVM_SUPPORT And may conditionally contain the following tag IDs: 8B (POI Information) 9F15 (Merchant Category Code)	Mandatory	--
Tag	Represents a data element. Can appear multiple times within container elements. Appears under the following elements: General - always present Reader_Limit_Set - only present when attribute Enabled ="True" Expected_Host_Response - only present when this container element is not empty	Conditional	0840, True, False, None Note: Tag data type can be either Hex value or Boolean or None. Empty enclosing tag <Tag/> means the configuration element shall be ignored (i.e. if the configuration exists, no change is needed and if configuration does not exist, ignore).
name	Attribute name under <Tag> element. Always present.	Mandatory	"Transaction Currency Code"
ID	Attribute ID under <Tag> element that refers to the equivalent Tag ID used by the test plan or specification. Always present.	Mandatory	"5F2A"
Exception_File_Check	A static element that represents the optional Terminal Exception File check feature as per VCPS Req 5.75. When attribute Enabled="True", the value represents the PAN content of the file. Always <Exception_File_Check Enabled="False"/> for VRTPKS	Mandatory	4761739001010010
Enabled	Attribute that represents whether the data element or feature is enabled or disabled for test case execution. Enabled="True" means the feature or data element shall be enabled and its value changed. Enabled="False" means that the feature or data element shall be disabled if supported or ignored if not supported. Appears under the following elements: Exception_File_Check Pre-processing DRL Tag Note: Pre-Processing feature cannot be disabled when supported. For Pre-processing, if Enabled = “False” means all individual Reader Risk Parameters Checking as per VCPS Section 5.3.2.2 shall be disabled.	Mandatory	"True", "False"
Pre-processing	A static container element that represents the Pre-processing feature as per VCPS Section 5.3.2. When Enabled=”True”, the elements within represents the configuration required for test execution. Contains below static elements when enabled: <Reader_Limit_Set> <Reader_Limit_Set_Cashback> <Reader_Limit_Set_ManaulCash> Note:When Enabled=”False” and if Pre-processing is implemented, all individual Reader Risk Parameters Checking as per VCPS Section 5.3.2.2 shall be disabled.	Mandatory	--
Reader_Limit_Set	Container element for default Reader Limit Set. This container is only present when Pre-processing or DRL is enabled. This tag can appear multiple times and contains the following Tag IDs: STATUS_CHECK CL_FLR_LIMIT_CHECK CVM_REQ_LIMIT_CHECK CL_TXN_LIMIT_CHECK ZERO_AMT_CHECK	Conditional	--
Reader_Limit_Set_Cashback	Container element for Cashback Reader Limit Set. This container is only present when Pre-processing is enabled and transaction type is Cashback.	Conditional	--
Reader_Limit_Set_ManualCash	Container element for Manual Cash Reader Limit Set. This container is only present when Pre-processing is enabled and transaction type is Manual Cash.	Conditional	--
DRL	A static container element that represents the Dynamic Reader Limits Functionality as per VCPS Section 5.5.4. When Enabled=”True”, the elements within represents the configuration required for test execution.	Mandatory	--
Program_ID_9F5A	Attribute Program ID of the container element Reader_Limit_Set. This attribute is only present when Reader_Limit_Set is within <DRL> element.	Conditional	"0108400840"
Expected_Host_Response	A static container element that represents the Host Response expected from the Host Simulator. It is the duty of the Reader Controller to pass this information to the Host Simulator. When this element is a closed tag <Expected_Host_Response/>, means that by default the Authorization Response Code (tag '8A') is "00" without Issuer Authentication Data (tag ‘91’) and without Issuer script template. Otherwise, the Host Response requires customization and contains the following tag IDs: 8A (Authorization Response Code) 91 (Issuer Authentication Data) ISSUER_SCRIPT (Issuer Script template, may contain either Template 71 or Template 72)	Mandatory	--
Certification_Revocation_List	A static element that represents the List of Certificates Revoked by the Certification Authority (CA). This element is always present. When this container is not empty, means that the feature as per EMV Book 2 Section 5.1.2 shall be enabled. Otherwise, a closed tag <Certification_Revocation_List/> means that the feature shall be disabled.	Mandatory	--
CRL_Entry	Element contained within Certification_Revocation_List. The value is a Hexadecimal string that is made up of : 5-bytes RID (Registered Application Provider Identifier) 1-byte CA PKI (Certification Authority Public Key Index) 3-bytes IPKC (Issuer Public Key Certificate) Serial Number Only present when <Certification_Revocation_List> is used (container is not empty).	Conditional	A00000000351000001
Online_ODA	A static element that represents the detailed configurations when ODA for qVSDC Online transactions feature is enabled. This element is always present.	Mandatory	--

2.4.1 General

Sample <General> element within <Configuration>

<Configuration Test_ID="T_5_85_C01_01" Config_ID="config_1" Info="VRTPKS Test Plan v1.2b,VRTPKS_Default" Version="1.2">
<General>
<Tag name="Transaction Currency Code" ID="5F2A">0840</Tag>
<Tag name="Transaction Currency Exponent" ID="5F36">02</Tag>
<Tag name="Transaction Type" ID="9C">01</Tag>
<Tag name="Amount, Authorized (Numeric)" ID="9F02">000000000200</Tag>
<Tag name="Amount, Other (Numeric)" ID="9F03">000000000000</Tag>
<Tag name="Terminal Country Code" ID="9F1A">0840</Tag>
<Tag name="Terminal Floor Limit" ID="9F1B"/>
<Tag name="Merchant Name and Location" ID="9F4E"/>
<Tag name="Online-Only Reader Enabled" ID="ONLINE_ONLY_READER_ENABLED">False</Tag>
<Tag name="AUC, Manual Cash Check Enabled" ID="AUC_MANUAL_CASH_CHECK_ENABLED">False</Tag>
<Tag name="AUC, Cashback Check Enabled" ID="AUC_CASHBACK_CHECK_ENABLED">False</Tag>
<Tag name="IRWIN, Do Not Transmit" ID="IRWIN_DO_NOT_TRANSMIT"/>
<Tag name="POI Information" ID="8B">0001020001</Tag>
<Tag name="Merchant Category Code" ID="9F15">9999</Tag>
<Tag name="TTQ - MSD Support" ID="TTQ_MSD_SUPPORT">False</Tag>
<Tag name="TTQ - qVSDC Support" ID="TTQ_QVSDC_SUPPORT">True</Tag>
<Tag name="TTQ - Offline Only Reader" ID="TTQ_OFFLINE_ONLY_READER">False</Tag>
<Tag name="TTQ - Online PIN Support" ID="TTQ_ONLINE_PIN_SUPPORT">False</Tag>
<Tag name="TTQ - Signature Support" ID="TTQ_SIGNATURE_SUPPORT">False</Tag>
<Tag name="TTQ - ODA For Online Authorization Support" ID="TTQ_ODA_FOR_ONLINE_AUTHORIZATION_SUPPORT">False</Tag>
<Tag name="TTQ - Mobile Functionality CDCVM Support" ID="TTQ_MOBILE_FUNCTIONALITY_CDCVM_SUPPORT">True</Tag>
</General>
…
</Configuration>

Table 2-2: Tags Present in <General>

Tag ID (Description)	Example Value	ICS Feature Dependency	Remarks
5F2A (Transaction Currency Code)	0840	--	--
5F36 (Transaction Currency Exponent)	02	--	--
9C (Transaction Type)	00	--	--
9F02 (Amount, Authorized (Numeric))	000000000200	--	--
9F03 (Amount, Authorized Other (Numeric))	000000000000	Cashback feature supported	--
9F1A (Terminal Country Code)	0840	--	--
9F1B (Terminal Floor Limit)	--	NOT SUPPORTED for VRTPKS	--
9F4E (Merchant Name and Location)	76697361206D65 726368616E74	--	--
9A (Transaction Date in YYMMDD format) (If a value is set, use this value to configure the Transaction Date. Otherwise, use the Reader-Terminal current date as the Transaction Date)	250930	--	--
9F06 (Terminal Application Identifier) (If a value set, use this value as the AID(s) to be supported by the Reader-Terminal. The value is expressed in an array form with a maximum of up to 10 values. Otherwise, use A000000003 as the default AID)	[A000000003, B0000000031010,B000000003101001]	--	--
ONLINE_ONLY_READER_ENABLED (Configuration to Enable or Disable the Online-Only processing feature of the Reader-Terminal)	True (always)	Always SUPPORTED for VRTPKS	--
AUC_MANUAL_CASH_CHECK_ENABLED (Configuration to Enable or Disable the processing restriction for Manual Cash transactions as described in VCPS Req 5.76])	True, False	Manual Cash feature supported	--
AUC_CASHBACK_CHECK_ENABLED (Configuration to Enable or Disable the processing restriction for Cashback transactions as described in VCPS Req 5.77])	True, False	Cashback feature supported	--
IRWIN_DO_NOT_TRANSMIT (Instruction to not transmit the given DE tag within IRWIN Message, the example value 57 means do not transmit tag ‘57’ Track 2 Equivalent Data within IRWIN Message)	--	NOT SUPPORTED for VRTPKS	--
TTQ_MSD_SUPPORT (Configuration to Enable or Disable the MSD support feature as in TTQ B1b8, always False for VCPS)	False (always)	--	--
TTQ_QVSDC_SUPPORT (Configuration to Enable or Disable the qVSDC support feature as in TTQ B1b6, always True for VCPS)	True (always)	--	--
TTQ_OFFLINE_ONLY_READER (Configuration to Enable or Disable the Offline-Only processing feature of the reader as in TTQ B1b4)	False (always)	NOT SUPPORTED for VRTPKS	--
TTQ_ONLINE_PIN_SUPPORT (Configuration to Enable or Disable the Online PIN CVM feature as in TTQ B1b3)	True, False	Online PIN feature supported	--
TTQ_SIGNATURE_SUPPORT (Configuration to Enable or Disable the Signature CVM feature as in TTQ B1b2)	True, False	Signature feature supported	--
TTQ_ODA_FOR_ONLINE_AUTHORIZATION_SUPPORT (Configuration to Enable or Disable the ODA for Online support feature as in TTQ B1b1)	True, False	Transit feature supported Following VRTPKS v1.2 False – Retail Mode True – Transit Mode	--
TTQ_MOBILE_FUNCTIONALITY_CDCVM_SUPPORT (Configuration to Enable or Disable the Mobile Functionality support (CD CDVM) as in TTQ B3b7, always True for VCPS)	True (always)	--	--
8B (POI Information as described in EMV SB 230. If the value is set to None, the POI Information is not set.)	0001020001, None	Transit feature supported	--
9F15 (Merchant Category Code, MCC as described in VRTPKS Appendix B. If the value is set to None, the MCC is not set.)	1000 to 9999, None	Transit feature supported	--

2.4.2 Pre-processing and DRL

Pre-processing as described in VCPS Section 5.3.2 and Dynamic Reader Limits (DRL) as described in VCPS Section 5.5.4 are optional features that is configurable to be enabled or disabled. For VRTPKS only the Reader CVM Required Limit Check VCPS Req 5.35 is supported.

Sample <Pre-processing> element within <Configuration>:

<Configuration Test_ID="T_Sample_01" Config_ID="config_1">
  ...
  <Pre-processing Enabled="True">
    <Reader_Limit_Set>
      <Tag name="Status Check" ID="STATUS_CHECK" Enabled="False"/>
      <Tag name="Reader Contactless Floor Limit Check" ID="CL_FLR_LIMIT_CHECK" Enabled="False"/>
      <Tag name="Reader CVM Required Limit Check" ID="CVM_REQ_LIMIT_CHECK" Enabled="True">000000005000</Tag>
      <Tag name="Reader Contactless Transaction Limit Check" ID="CL_TXN_LIMIT_CHECK" Enabled="False"/>
      <Tag name="Zero Amount Check" ID="ZERO_AMT_CHECK" Enabled="False"/>
    </Reader_Limit_Set>
    <Reader_Limit_Set_Cashback/>
    <Reader_Limit_Set_ManualCash/>
  </Pre-processing>
  ...
</Configuration>

Sample <DRL> element within <Configuration>:

<Configuration Test_ID="T_Sample_01" Config_ID="config_1">
  ...
  <DRL Enabled="True">
    <Reader_Limit_Set Program_ID_9F5A="0108400840">
      <Tag name="Status Check" ID="STATUS_CHECK" Enabled="False"/>
      <Tag name="Reader Contactless Floor Limit Check" ID="CL_FLR_LIMIT_CHECK" Enabled="False"/>
      <Tag name="Reader CVM Required Limit Check" ID="CVM_REQ_LIMIT_CHECK" Enabled="True">000000000100</Tag>
      <Tag name="Reader Contactless Transaction Limit Check" ID="CL_TXN_LIMIT_CHECK" Enabled="False"/> 
      <Tag name="Zero Amount Check" ID="ZERO_AMT_CHECK" Enabled="False"/>
    </Reader_Limit_Set>
    <Reader_Limit_Set Program_ID_9F5A="0208400840">
      <Tag name="Status Check" ID="STATUS_CHECK" Enabled="False"/>
      <Tag name="Reader Contactless Floor Limit Check" ID="CL_FLR_LIMIT_CHECK" Enabled="False"/>
      <Tag name="Reader CVM Required Limit Check" ID="CVM_REQ_LIMIT_CHECK" Enabled="True">000000000200</Tag>
      <Tag name="Reader Contactless Transaction Limit Check" ID="CL_TXN_LIMIT_CHECK" Enabled="False"/> 
      <Tag name="Zero Amount Check" ID="ZERO_AMT_CHECK" Enabled="False"/>
    </Reader_Limit_Set>
    <Reader_Limit_Set Program_ID_9F5A="0308400840">
      <Tag name="Status Check" ID="STATUS_CHECK" Enabled="False"/>
      <Tag name="Reader Contactless Floor Limit Check" ID="CL_FLR_LIMIT_CHECK" Enabled="False"/>
      <Tag name="Reader CVM Required Limit Check" ID="CVM_REQ_LIMIT_CHECK" Enabled="True">000000000300</Tag>
      <Tag name="Reader Contactless Transaction Limit Check" ID="CL_TXN_LIMIT_CHECK" Enabled="False"/> 
      <Tag name="Zero Amount Check" ID="ZERO_AMT_CHECK" Enabled="False"/>
    </Reader_Limit_Set>
    <Reader_Limit_Set Program_ID_9F5A="0408400840">
      <Tag name="Status Check" ID="STATUS_CHECK" Enabled="False"/>
      <Tag name="Reader Contactless Floor Limit Check" ID="CL_FLR_LIMIT_CHECK" Enabled="False"/>
      <Tag name="Reader CVM Required Limit Check" ID="CVM_REQ_LIMIT_CHECK" Enabled="True">000000000400</Tag>
      <Tag name="Reader Contactless Transaction Limit Check" ID="CL_TXN_LIMIT_CHECK" Enabled="False"/> 
      <Tag name="Zero Amount Check" ID="ZERO_AMT_CHECK" Enabled="False"/>
    </Reader_Limit_Set>
  </DRL>
  ...
</Configuration>

Table 2-3: Tags Present in <Pre-processing> and <DRL>

Tag ID (Description)	Example Value	ICS Feature Dependency	Remarks
STATUS_CHECK (Status Check as described in VCPS Req 5.31)	--	Always Enabled=”False” for VRTPKS	--
CL_FLR_LIMIT_CHECK (Reader Contactless Floor Limit Check as described in VCPS Req 5.36. Note: When this tag attribute Enabled=”True” and value is empty i.e. closed tag, this means that the check is enabled but the Reader Contactless Floor Limit is not present. Terminal floor limit (tag ‘9F1B’) from is used instead.)	--	Always Enabled=”False” for VRTPKS	--
CVM_REQ_LIMIT_CHECK (Reader CVM Required Limit Check as described in VCPS Req 5.35)	000000005000	CVM Required Limit Check is supported or Dynamic Reader Limit is supported	--
CL_TXN_LIMIT_CHECK (Reader Contactless Transaction Limit (RCTL) Check as described in VCPS Req 5.34)	--	Always Enabled=”False” for VRTPKS	--
ZERO_AMT_CHECK (Amount, Authorized of Zero Check as described in VCPS Req 5.32 and Req 5.33. For Online-Capable related tests, there are 2 possible values: Value of 01 refers to Option 1, Value of 02 refers to Option 2. For Offline-Only related tests, there will be no value set)	--	Always Enabled=”False” for VRTPKS	--

2.4.3 Expected Host Response

<Expected_Host_Response> element contains the customized expected response from Product Provider’s Host Simulator. This container element contains sub elements only when the test case needs to simulate a customized host response. When sub elements are present , the Host Simulator shall be configured to manipulate the Host Response according to the sub elements (Authorization Response Code, Issuer Authentication Data, and/or Issuer Script).

• Note: If automation is supported, the Reader Controller shall communicate the sub elements (Authorization Response Code, Issuer Authentication Data, and/or Issuer Script) details with the Host Simulator to manipulate the Host Response.

A closed tag <Expected_Host_Response/> means that by default the host response shall be an Approval without any Issuer Script Processing.

Sample <Expected_Host_Response> element within <Configuration>:

<Configuration Test_ID="T_5_85_C01_01" Config_ID="config_1">
  ...
  <Expected_Host_Response>
    <Tag name="Authorization Response Code" ID="8A">00</Tag>
    <Tag name="Issuer Authentication Data" ID="91">1234567803820000</Tag>
    <Tag name="Issuer Script" ID="ISSUER_SCRIPT">71169F180400000001860D841E0000081234567890123456</Tag>
  </Expected_Host_Response>
  ...
</Configuration>

Table 2-4: Tags present in <Expected_Host_Response>

Tag ID (Description)	Example Value	ICS Feature Dependency	Remarks
Expected_Host_Response	--	Always supported for VRTPKS	--
8A (Authorization Response Code) The value is a 2-byte string e.g. 00 means ‘3030’ in hex. If the value is set to None, the test expectation is a No Host Response) Note: • 00, 10, or 11 indicates an issuer approval. • 01 or 02 indicates an issuer referral. • An ARC other than the ones listed above indicates an issuer decline.	00, 03, 11, 12, 13, 23, None	--	--
91 (Issuer Authentication Data) If the value is set to None, this means that the Host Simulation shall not return Issuer Authentication Data in the Host Response. Also, the test does not expect the Reader/Terminal to send an EXTERNAL_AUTHENTICATE command at Second Tap)	1234567803820000, None	NOT SUPPORTED for VRTPKS	--
ISSUER_SCRIPT (Issuer Script) If the value is set to None, this means that the Host Simulation shall not return Issuer Scripts in the Host Response. Also, the test does not expect the Reader/Terminal to send any ISSUER SCRIPT command at Second Tap)	71169F180400000001860D841E0000081234567890123456, None	NOT SUPPORTED for VRTPKS	--

2.4.4 Certification Revocation List

A reader-terminal may support a Certification Revocation List (CRL) that lists the Issuer Public Key Certificates that payment systems have revoked. If a test requires certificate(s) to be revoked, each <CRL_Entry> element represents a certificate in the list.

Sample <Certification_Revocation_List> element within <Configuration>:

<Configuration Test_ID="T_5_85_C01_01" Config_ID="config_1">
…
<Certification_Revocation_List>
<CRL_Entry>A00000000351000001</CRL_Entry>
<CRL_Entry>A00000000351000002</CRL_Entry>
</Certification_Revocation_List>
…
</Configuration>

Table 2-5: Tags present in <Certification_Revocation_List>

Tag ID (Description)	Example Value	ICS Feature Dependency	Remarks
CRL_Entry in 9 bytes Hex String format: Registered Application Provider Identifier (RID) (first 5 bytes) Certification Authority Public Key Index (next 1 byte) Certificate Serial Number (next 3 bytes)	A00000000351000001	Key Revocation supported	-

2.4.5 Online ODA

Offline Data Authentication (ODA) for qVSDC Online transactions feature as described in VRTPKS specification.

If supported and enabled, the tag ID “TTQ_ODA_FOR_ONLINE_AUTHORIZATION_SUPPORT” in <General> section will be set to True while running with the VRTPKS Test Plan in Transit mode (TTQ B1b1 is set to 1b).

Sample <Online_ODA> element within <Configuration>:

<Configuration Test_ID="T_5_85_C01_01" Config_ID="config_1">
…
<Online_ODA>
     <Tag name="SDA Enabled" ID="SDA_ENABLED">False</Tag>
     <Tag name="fDDA Enabled" ID="fDDA_ENABLED">True</Tag>
</Online_ODA>
…
</Configuration>

Table 2-6: Tags present in <Online_ODA>

Tag ID (Description)	Example Value	ICS Feature Dependency	Remarks
SDA_ENABLED	False	NOT SUPPORTED for VRTPKS	-
fDDA_ENABLED	True	Transit feature supported	-

3 Online-Only

VRTPKS implementation shall always set TTQ B2b8 (Online Cryptogram Required) to 1b regardless of the Reader Risk Parameter settings specified in <Reader_Limit_Set>.

4 AID

The product-under-test must initialize Tag 9F06 (Application Identifier (AID) - Terminal) with the default value “A000000003”. If an alternate value for tag 9F06 is received by the reader controller, this value shall be overridden with the specified value(s).

Note: As per VCPS Req 5.47, ADF Name matching by full match and by partial match are to be supported and enabled by default.

5 Date Time Requirement

The VRTPKS Test Plan is compliant to run with Reader/Terminal internal date time set from June 1, 2017 and onwards.

By default, the product-under-test is expected to use the current date and time to process Tag 9A (Transaction Date). If an alternate value for Tag 9A is received by the reader controller, it shall be overridden with the specified value.

Appendix A Test Message

This section defines the flow, protocol, expectations and message handling between the Reader Controller (herein referred to as "client") and the Test Tool (herein referred to as "server") during the Test Message exchange.

Test Message utilizes the HTTP Protocol that is a TCP/IP based communication protocol. Hence, requires the server application to listen to an open TCP/IP socket (IP Address and Port) and the client application to send/receive HTTP Messages over the open socket. This architecture is synchronous and is applicable only for one-to-one communication with server and client (cannot be one-to-many).

Note: The IP Address and Port shall not be static and shall be made configurable by the client and server applications.

A.1 Overview

A.2 HTTP Message

Throughout the test messaging, below structure of HTTP Request and Response message (as defined in RFC 7230 and RFC 7231) are used. Below tables are for reference only. The parameters and values shown in these tables are recommended but shall not be mandated by the server or client applications.

HTTP – Request message

Entity	Description
Request Line	request-method-name request-URI HTTP-version GET / HTTP/1.1 POST / HTTP/1.1 TRACE / HTTP/1.1
Request Headers	request-header-name: request-header-value1, request-header-value2, ... Message: [Name of message] Host: [IP Address]:[Port] Connection: keep-alive If Request message body exists: Content-Type: text/plain
-	BLANK LINE
Request Message Body	XML Data (Conditional)

HTTP – Response message

Entity	Description
Status Line	HTTP-version status-code reason-phrase HTTP/1.1 200 OK (Other status-codes to be defined)
Response Headers	response-header-name: response-header-value1, response-header-value2, ... Accept-Ranges: bytes Connection: keep-alive If Response message body exists: Content-Type: text/plain
-	BLANK LINE
Response Message Body	XML Data (Conditional)

Note: Requirements for Bad format checks are further discussed in A.6.2 General - Bad Request Format.

Sample Exchange

GET / HTTP/1.1
Message: STXN
Host: localhost:8080
Connection: keep-alive
HTTP/1.1 200 OK 
Date: Wed, 18 Oct 2017 08:56:53 
Accept-Ranges: bytes
Connection: keep-alive 
Content-Length: 116
Content-Type: text/plain

<Configuration Test_ID="T_001"><Tag name="Amount, Authorized (Numeric)" ID="9F02">000000000001</Tag></Configuration>

POST / HTTP/1.1
Message: ETXN
Host: localhost:8080
Connection: keep-alive
Content-Length: 140
Content-Type: text/plain

<Transaction_Details><Test_ID>T_0001</Test_ID><Transaction_Outcome>20</Transaction_Outcome><AcquirerData/><IRWINData/></Transaction_Details>
HTTP/1.1 200 OK 
Date: Wed, 18 Oct 2017 08:57:14 
Accept-Ranges: bytes 
Connection: keep-alive 

A.3 Start of Transaction (STXN)

STXN is a message sent by the Reader Controller to the Test Tool to indicate that the reader-terminal is ready to start a transaction. Reader-Terminal configuration is sent back as the message response.

HTTP Request

Entity	Description	Comments
Request Line	GET/HTTP/1.1	Use GET method
Request Headers	Message: STXN Host: [IP Address]:[Port] Connection: keep-alive	-

HTTP Response

Entity	Description	Comments
Status Line	HTTP/1.1 [status-code reason-phrase]	status-code reason-phrase: 200 OK (success, ACK) 204 No Content (no more test) 400 Bad Request Format (malformed request syntax) 408 Request Timeout (server is busy, try again later) 409 Conflict (multiple updates) Others (server exception)
Response Headers	Connection: keep-alive Content-Type: text/plain	-
Resonse Message Body	XML Data	XML Data that contains the Reader-Terminal Configuration in order to perform the test. See Section 2.4 for the XML content.

A.4 End of Transaction (EXTN)

ETXN is a message sent by the Reader Controller to the Test Tool to indicate that the transaction in the reader-terminal has completed. The Transaction outcome details are submitted to the server as part of the message request.

HTTP Request

Entity	Description	Comments
Request Line	POST/HTTP/1.1	Use POST method
Request Headers	Message: EXTN Host:[IP Address]:[Port] Connection:keep-alive Content-Type: text/plain	-
Request Message Body	XML Data	XML Data that contains the transaction outcome details. See Sample <Transaction_Details> and Table A-1: XML Elements and Attributes within <Transaction_Details> for details

HTTP Response

Entity	Description	Comments
Status Line	HTTP/1.1 [status-code reason-phrase]	status-code reason-phrase: 200 OK (success, ACK) 204 No Content (no more test) 400 Bad Request Format (malformed request syntax) 408 Request Timeout (server is busy, try again later) 409 Conflict (multiple updates) Others (server exception)

Note: A 200 status code is merely an acknowledgement response of the message regardless whether the test case verdict is a pass or fail.

Sample <Transaction_Details>

<Transaction_Details>
   <Test_ID>T_001</Test_ID>
   <Transaction_Outcome>20</ Transaction_Outcome>
   <AcquirerData>  
      <DE_9F02>000000000200</DE_9F02>
      <DE_9F03>000000000000</DE_9F03>
      <DE_9F26>1122334455667788</DE_9F26>
      <DE_82>0020</DE_82>
      <DE_9F36>0001</DE_9F36>
      <DE_5F34>00</DE_5F34>
      <DE_9F7C>010203040500FF</DE_9F7C>
      <DE_9F6E>20400000</DE_9F6E>
      <DE_9F10>06011203A00000</DE_9F10>
      <DE_9F39>07</DE_9F39>
      <DE_9F1A>0840</DE_9F1A>
      <DE_TERMINAL_ENTRY_CAPABILITY>05</DE_TERMINAL_ENTRY_CAPABILITY>
      <DE_95>0000000000</DE_95>
      <DE_5F2A>0840</DE_5F2A>
      <DE_9A>180521</DE_9A>
      <DE_9C>00</DE_9C>
      <DE_9F37>11223344</DE_9F37>
      <DE_9F5B/>
      <DE_9F24/>
      <DE_57>4761739001010010D20122011234599999991F</DE_57>
   </AcquirerData>
   <IRWINData/>
</Transaction_Details>

Table A-1: XML Elements and Attributes within <Transaction_Details>

XML Element / Attribute	Description	Presence	Example Value
Transaction_Details	Container element for Transaction Details below static elements (always present): <Test_ID> <Transaction_Outcome> <AcquirerData> <IRWINData>	Mandatory	-
Test_ID	Contains the Unique Identifier of the test case Note: This shall reflect the equivalent test case ID as received from the STXN message. Otherwise, the server shall decline acknowledgement of ETXN message.	Mandatory	T_001
Transaction_Outcome	Contains a 1-byte representation of the Transaction Outcome in Hex String format. This byte is reset to 0x00 at the beginning of a transaction. The left nibble of the byte indicates the transaction outcome (bits 8-5) ‘0’ = Offline Approval ‘1’ = Offline Decline ‘2’ = Online Approval ‘3’ = Online Decline ‘E’ = Switch ‘F’ = Terminate Others = RFU The right nibble of the byte indicates the reader-terminal verification results (bits 4-1) bit 4: 1 = SDA performed bit 3: 1 = fDDA performed bit 2: 1 = If either SDA/fDDA is performed but unsuccessful/failed, set to 1b bit 1: 1 = If card application is expired, set to 1b Note: Reader-terminal verification results (bits 4-1) are to be populated when transit feature is supported and enabled (if TTQ B1b1 is set to 1b – Transit).	Mandatory	04, 06, 20, 30, E0, F0…
DE_<tag>	DE element that represents a tag and value in a list.	Conditional	<DE_9F02>000000000200</DE_9F02>
AcquirerData	Container element for data elements that are available to the acquirer for inclusion in online messages and clearing records. The reader-terminal is not prohibited from providing other data in addition to the minimum data specified in the list. Acquirer Data shall be populated for all Offline Approval, Offline Decline, Online Approval and Online Decline transactions. See Table A-3 for the list of Data Elements to be populated. Note: For Switch and/or Terminate transactions this shall be an empty container element <AcquirerData/>	Mandatory	--
IRWINData	Value is always <IRWINData/> for VRTPKS	Mandatory	--

All XML Element tags listed below represents the minimum data to be included in <AcquirerData> container element for a VRTPKS kernel.

If the Data Element is available for inclusion in online messages and clearing records, the value shall be populated with Hexadecimal string and left-padded with zeroes ‘0’ to meet the length requirement.

Otherwise, if the data element is not available, the XML element tag shall be populated as a closed tag. Refer to VCPS/VRTPKS specification for requirements when the value shall be present or conditional to be present.

Table A-2: XML Elements within <AcquirerData>

XML Element	Description	Length Requirement (in bytes, to be multiplied by 2 when expressed to Hexadecimal string)
DE_9F02	Amount, Authorized	6
DE_9F03	Amount, Other	6
DE_9F26	Application Cryptogram	8
DE_82	Application Interchange Profile	2
DE_9F36	Application Transaction Counter (ATC)	2
DE_5F34	Card Sequence Number	1
DE_9F7C	Customer Exclusive Data	As received from Card response
DE_9F6E	Form Factor Indicator	4
DE_9F10	Issuer Application Data	As received from Card response
DE_9F39	POS Entry Mode	1
DE_9F1A	Terminal Country Code	2
DE_TERMINAL_ENTRY_CAPABILITY	Terminal Entry Capability	1
DE_95	Terminal Verification Results	5
DE_5F2A	Transaction Currency Code	2
DE_9A	Transaction Date	3
DE_9C	Transaction Type	1
DE_9F37	Unpredictable Number (Reader-Terminal)	4
DE_9F5B	Issuer Script Results	1 or 5
DE_9F24	Payment Account Reference (PAR)	As received from Card response
DE_57	Track 2 Equivalent Data	As received from Card response
DE_5F20	Card Holder Name	As received from Card response
DE_96	Kernel Identifier – Terminal	8
DE_9F0A	Application Selection Registered Proprietary Data (ASRPD)	8
DE_BF0C_DF30	VISA Fleet Data Object – Prompting Tag	Var
DE_ BF0C_DF32	VISA Fleet Data Object – Purchase Restrictions	Var
DE_ BF0C_DF40	VISA Fleet Data Object – Generic ID	Var
DE_BF0C_DF41	VISA Fleet Data Object – Vehicle ID	Var
DE_BF0C_DF43	VISA Fleet Data Object – Driver ID	Var
DE_BF0C_DF52	VISA Fleet Data Object – Fleet Trailer Number	Var
DE_BF0C_DF53	VISA Fleet Data Object – Fleet Employee Number	Var
DE_BF0C_DF54	VISA Fleet Data Object – Fleet Work Order/Purchase Order Number	Var
DE_BF0C_DF55	VISA Fleet Data Object – Fleet Additional Prompted Data 1	Var
DE_BF0C_DF56	VISA Fleet Data Object – Fleet Additional Prompted Data 2	Var

Notes:

• DE_96 is mandatory if the product is compliant to the [VCPS APP SELECTION] specifications.
• DE_9F0A and DE_BF0C_[tag id] are optional data and are only required for terminals supporting output of ASRPD and VISA Fleet Data Objects.

A.5 ECHO

ECHO is an administrative message for the Reader Controller to check the end-to-end communication between the client and the server

HTTP Request

Entity	Value	Comments
Request Line	TRACE / HTTP/1.1	Use TRACE method
Request Headers	Message: ECHO Host: [IP Address]:[Port] Connection: keep-alive	-

HTTP Response

Entity	Value	Comments
Status Line	HTTP/1.1 [status-code reason-phrase]	status-code reason-phrase 200 OK (success, ACK) 400 Bad Request Format (malformed request syntax) 408 Request Timeout (server is busy, try again later) Others (fail)
Response Headers	Connection: keep-alive Content-Type: text/plain	-
Response Message Body	[Content of the HTTP Request header(s)]	Echoes back the content of the HTTP Request headers

A.6 Scenarios and Error Handling

A.6.1 General - No Host Response

When a test process begins, Server socket connection shall always be available to the client throughout the duration of the process. Client shall be able to handle when there is no host/server response. This indicates connection failure with the host.

A.6.2 General - Bad Request Format

The Server shall check the message syntax when it receives message from the client (e.g. bad or missing expected request header "Message"). Server shall return 400 Bad Request Format status code, which indicates that the request syntax is malformed.

Message syntax check shall include the following conditions. In the event that any of below condition is not met, the server shall return 400 Bad Request Format:

• Header Message value shall not be null and shall be equal to "STXN", "ETXN" or "ECHO" (case-sensitive).
• ETXN request Message body content shall not be null, and shall contain all following keywords (case-sensitive)
  • <Transaction_Details>
  • </Transaction_Details>
  • <Test_ID>
  • </Test_ID>
  • <Transaction_Outcome>
  • </Transaction_Outcome>
• ETXN request Test ID received should be the same value as the current Test ID (case-sensitive) or the Test ID sent from the last STXN response.

A.6.3 General - Server Busy, Request Timeout

When a client sends a message and the Server is Busy, a 408 Request Timeout status code shall be returned. This indicates that the server is busy and the client can try to re-send the same message later.

Recommended Settings (Below setting constitutes a total of 5 minutes of retries – allows the human tester to view the visual checks and respond accordingly. This setting must be configurable at client side.)

• Delay: 1 second
• Number of retries: 300

Note: For status codes other than 408, automatic retry is not applicable.

A.6.4 General - Error Message

If the status code is not 200 or not 204 or 408 and the number of retries are exhausted (if applicable) then the client shall indicate an error message displaying minimally the "status-code reason-phrase" to the user and terminate the testing process.

A.6.5 Connection and Messaging Protocol Test

A 200 status code for TRACE, Echo means network connection and messaging protocols are both ok. Status code other than 200 indicates further troubleshooting is required.

A.6.6 Test Execution

Below flow summarizes the client-server message exchange during a test execution. Before the test process starts, the server shall prepare the list of Test_IDs to run.

The list of Test_IDs to run depends on the type of run the Test Tool user prefers:

a. Single run – execute a single test case (run-one-by-one)

b. Batch run – execute the full batch of test cases (run-full-batch)

A Test_ID shall adapt a test cycle that minimally consists of three states:

1. begin – the beginning state, where the Test_ID have never been sent or have never been completed.
2. sent – the sent state is where the server receives a Start-of-Transaction message and this Test_ID have been sent to the client.
3. completed – the completed state is when the server receives an End-of-Transaction message for the Test_ID and the response status code is 200 (OK).

When the server has exhausted the list of Test_IDs (i.e. no more test case to run), the server shall respond Start-of-Transaction message with 204 status code.

a. Single Run

b. Batch Run

A.6.7. Test Execution - Stop on Error

The test tool shall have an option for users to enable the Stop-On-Error function. This functionality enables the Test Tool to "pause" the test process when Product-under-test has failed a test. This enables the user to investigate the cause of failure before resuming the test process. When a test process is paused, the test tool shall memorize the test case context so that the process can continue to the next test case when resumed.

When Stop-On-Error function is enabled and a verdict for the last test case is a FAIL, the server shall reply with a 204 status code. A 204 status code shall make the client application stop or pause the test process. When the client application starts again the test process, the server shall respond with the next Test_ID with state == begin.

Note: If the test verdict is not yet available (this is true for some test cases that requires extra Visual Check(s)), the server may reply with "Server is Busy" 408 return code. See Appendix A.6.3.

A.6.8 Multiple Start of Transaction (STXN) Messages

Below illustration shows the expected server behavior when multiple STXN message is received. In this case, the server shall respond with the last Test_ID in "sent" state.

A.6.9 Multiple End of Transaction (ETXN) Messages

Below illustration shows the expected server behavior when multiple ETXN message is received. In this case, the server shall check that the Test_ID is the same with the last Test_ID (where last message is ETXN message). If the Test_ID is the same, the server shall overwrite the transaction outcome from the new ETXN message and shall invoke the Test Tool to re-do validation of the test.

A.6.10 End of Transaction (ETXN) Message with Wrong Test_ID

When the server receives an ETXN message, it shall validate that the Test_ID match the last Test_ID (from the last STXN message or last ETXN message). If it does not match, the server shall reply with 400 status code (Bad Request Format).

A.6.11 Echo in Between Messages

Echo is an administrative message to test end-to-end client-server communication. Test case or test process shall not be affected in any way by an Echo message.

A.6.12 Unexpected Flow of Message

When an incoming message is unexpected by the server (i.e. End-of-Transaction message is received for a Test_ID when test state==begin) the server shall reply 400 status code (Bad Request Format).

Appendix B Reader Status and Event

The following Events and Checks are passing criteria to the VRTPKS Test Plan. This section is only informational to Product Providers and serves as a guide for the expected visual checks required for Level 2 Type Approval.

B.1 Outcome Events

Status/Event	Description
EVT_NOTIFY_OUTCOME_APPROVED	The reader shall indicate to the cardholder and merchant that the transaction has been approved.
EVT_NOTIFY_OUTCOME_DECLINED	The reader shall decline the transaction and indicate to the cardholder and merchant that the transaction has been declined.
EVT_NOTIFY_SWITCH_INTERFACE	If the reader supports another interface, the reader shall prompt to insert or swipe card
EVT_NOTIFY_TERMINATE	The reader (or terminal) shall clearly communicate to the cardholder and merchant the outcome of the transaction - Terminate
EVT_NOTIFY_SWITCH_OR_TERMINATE	Either of the behavior described for below events is acceptable: EVT_NOTIFY_SWITCH_INTERFACE EVT_NOTIFY_TERMINATE
EVT_NOTIFY_ANY_COMPLETION_OUTCOME	The reader shall indicate any transaction completion outcome (Approved or Declined). The reader shall not indicate any error or terminate the transaction.
EVT_NOTIFY_OUTCOME_DECLINED_OR_TERMINATE	Either of the behavior described for below events is acceptable: EVT_NOTIFY_OUTCOME_DECLINED EVT_NOTIFY_TERMINATE

B.2 Other Events

Status/Event	Description
EVT_COLLISION_ERROR	The reader shall indicate that multiple contactless cards are detected by the reader and shall request placement of a single payment card.
EVT_REQUEST_PRESENT_CARD	The reader shall request for card to be presented
EVT_REMOVE_CARD_IN_PROGRESS	The reader shall indicate to the cardholder and merchant that card read is complete and that the card may be removed, but that the transaction is still in progress.
EVT_REFER_TO_PAYMENT_DEVICE	The reader shall indicate to the cardholder to refer to their payment device for further instructions and immediately power down the contactless interface. After a duration of between 1000ms and 2000ms, the reader shall power up the contactless interface and return to Discovery Processing.Any message displayed to the cardholder shall continue to be displayed during the subsequent Discovery Processing.
EVT_NOTIFY_DISPLAY_AMOUNT	The reader shall display the Amount, Authorized (tag 9F02) when prompting for a card to be presented.
EVT_ONLINE_PIN_PERFORMED	Verify that the Online PIN processing is performed
EVT_ONLINE_PIN_NOT_PERFORMED	Verify that the Online PIN processing is not performed
EVT_SIGNATURE_ACQUIRED	Verify that the Signature is acquired
EVT_SIGNATURE_NOT_ACQUIRED	Verify that the Signature is not acquired
EVT_AID_PRINTED	Verify that the Application Identifier (AID) value is fully printed as hexadecimal characters by the reader
EVT_FDDA_VERIFICATION_NOT_PERFORMED	The transit kernel shall indicate that Fast Dynamic Data Authentication (fDDA) verification is not performed
EVT_FDDA_VERIFICATION_PERFORMED_AND_SUCCESSFUL	The transit kernel shall indicate that Fast Dynamic Data Authentication (fDDA) verification is performed and successful
EVT_FDDA_VERIFICATION_PERFORMED_AND_FAILED	The transit kernel shall indicate that Fast Dynamic Data Authentication (fDDA) verification is performed and failed
EVT_APPLICATION_EXPIRED	The transit kernel shall indicate that the Card Application is expired
EVT_APPLICATION_NOT_EXPIRED	The transit kernel shall indicate that the Card Application is not expired
EVT_ONLINE_REQUIRED_BY_READER_INDICATOR_SET_TO_1b	The transit kernel shall indicate that Online Required by Reader Indicator is set to 1
EVT_ONLINE_REQUIRED_BY_READER_INDICATOR_SET_TO_0b	The transit kernel shall indicate that Online Required by Reader Indicator is set to 0
EVT_DECLINE_REQUIRED_BY_READER_INDICATOR_SET_TO_1b	The transit kernel shall indicate that Decline Required by Reader Indicator is set to 1
EVT_DECLINE_REQUIRED_BY_READER_INDICATOR_SET_TO_0b	The transit kernel shall indicate that Decline Required by Reader Indicator is set to 0

B.3 Additional Checks

Check	Description
CHK_EXP_ACQ_DATA	Perform check to match the expected Acquirer Data content. Acquirer Data refers to the Online Authorization Message and/or Clearing Message to the Acquirer. Only the content is required to be matched (whether the data shall be present or shall not be present and if present shall be matched). The actual messaging protocol is not defined and is out of scope from this document.
CHK_APDU_LOG	Perform check on the APDU log. APDU log refers to the message exchange unit between the "Card" smart card emulation and the smart card Reader referred here as APDU (Application Protocol Data Unit).

Appendix C Reader Controller Verifier Tool

The Reader Controller Verifier tool allows developers to assist in development of their own Reader Controller implementations. This section describes the detailed usage of the tool.

1. Dropdown box to choose a scenario.
2. User toolbar:
   • RUN button to simulate the scenario
   • STOP button to stop the simulation
   • ERASE button to erase the display logs
3. Dropdown box to choose test case to run if running in Single Run mode or the test case to start with if running in Batch Run mode.
4. Non-editable, specifies the server address. By default, this tool can only run in localhost.
5. Specifies the TCP/IP server port to listen to.
6. Server configuration to simulate some of the test messaging scenarios

Scenarios: In order to check the Reader Controller implementation, run all scenarios listed in the List of Compliance Scenarios table below. Other scenarios are available for development purpose and for simulation only.

List of Compliance Scenarios

Scenario	Description/Reference
Single Run	Simulates the Test Execution - Single Run scenario as described in Appendix A.6.6a
Batch Run	Simulates the Test Execution – Batch Run scenario as described in Appendix A.6.6b
Batch Run - Server Busy at beginning	Simulates the Test Execution – Batch Run with Server Busy scenario as described in Appendix A.6.3. The server will be busy at the beginning of the batch run.
Batch Run - Server Busy at middle	Simulates the Test Execution – Batch Run with Server Busy scenario as described in Appendix A.6.3. The server will be busy in the middle of the batch run.

Other Scenarios

Scenario	Description/Reference
Stop on Error	Simulates the server side scenario A.6.7 Test Execution – Stop On Error Note: Available at the settings panel of Reader Controller Verifier tool.
Always No Host Response	Simulates the server side scenario A.6.1 General - No Host Response Note: Available at the settings panel of Reader Controller Verifier tool.
Always Reply Error Message	Simulates the server side scenario A.6.4 General – Error message Note: Available at the settings panel of Reader Controller Verifier tool.
Messaging Protocol Test	By default, these scenarios are handled consciously by the server while running the compliance scenarios: A.6.2 General – Bad Request Format A.6.5 Connection and Messaging Protocol Test A.6.8 Multiple Start of Transaction (STXN) message A.6.9 Multiple End of Transaction (ETXN) message A.6.10 End of Transaction (ETXN) message with wrong Test_ID A.6.11 Echo in between messages A.6.12 Unexpected Flow of Message

Visual Check Requirement: Some of the tests will require Visual Check Requirements confirmations from the user depending on the test requirement. This aims to notify the user to observe the reader/terminal and confirm that it behaves as expected.

Note: Confirmation of visual check requirements is part of the passing criteria for these type of tests.

Test Result:

The test result panel lists down the test cases and indicates a GREEN dot when a test case verdict is a Pass and a RED dot when the test case verdict is a Fail.

In this simulation, the Reader Controller Verifier tool will only compare the Transaction Outcome content from ETXN message against the expected from the test case. The pass/fail verdict does not simulate the entire verdict logic of a test tool that will also include APDU matching and complete visual check validations against Reader Status and Event.

Log files are automatically saved and is available in {user path.visasim.rcverifier}\log folder.

Appendix D Frequently Asked Questions (FAQ)

D.1 General

Q: What does Clearing Record means?

A: The collection and delivery to the issuer of a completed transaction record from an acquirer. The completed transaction can either be Offline Approval, Offline Decline, Online Approval and/or Online Decline transactions.

Q: Will the tester check the APDUs on the Test Tool side or on the terminal side?

A: The APDUs will be logged and are checked at the Test Tool side.

D.2 Architecture and Protocol Handling

Q: Our Reader Controller implementation does not have a connection to an external Host Simulator. The Reader Controller itself acts as the Host Simulator. Whenever a transaction requests for an online authorization, the equivalent content of <Expected_Host_Response> will be communicated to the terminal directly. Can it be implemented in this way?

A: Yes, this is allowed. There is no restriction where the Host Simulator shall reside.

Q: Is there any special mode required for Client to send ECHO in between messages when test is in processing? If not, ECHO message will be sent to Server only when the tester wants to check the connection status.

A: There is no specific requirement or special mode to use ECHO in between messages. It is not required but it is possible to do so.

D.3 Product Features and Configurations

Q: Our product solely supports Online only configuration (our product does not support Offline only configuration and Both Online and Offline Capable configuration), but I received the following element disabled, do I need to handle this data? <Tag ID="ONLINE_ONLY_READER_ENABLED" name="Online-Only Reader Enabled">False</Tag>

A: If your product does not support disabling Online only configuration, you do not need to handle this data. Online only configuration shall remain enabled all throughout test execution.

Q: Both the values of Transaction Type (tag 9C) for Purchase without cashback and Purchase with cashback are ’00’. How can I distinguish them to perform a transaction?

A: Transaction type (tag 9C) for both Purchase without cashback and Purchase with cashback is '00'. You can distinguish cashback amount by checking that Amount, Other (tag 9F03) value is greater than zero '000000000000'. If the value is greater than zero, the transaction is Purchase with cashback. Otherwise, it is a Purchase without cashback.

Q: Purchase with cashback have two amounts, Amount, Authorized (tag 9F02) and Amount, Other (tag 9F03) which amount shall I use for Reader Risk Processing?

A: Amount, Authorized (tag 9F02) is the amount used for Reader Risk Processing. VCPS specifications (Req 5.18, 2nd bullet) states that Amount, Authorized (tag 9F02) is the sum of the Purchase Amount and the Cashback amount (if present and known).

Q: Test 03 is by default set as NA. However, when I execute “Batch Run - Test 1 to 20”, the RC Verifier stops as Test 03 has failed. Is there a way to continue even if a test has failed?

A: In RC Verifier settings panel, uncheck the “Stop on Error” feature. This will enable the RC Verifier to continue even if a test case has failed verification.